Theme switching ESLint rules #32569

chrispader · 2023-12-06T15:48:21Z

Details

Add ESLint rules to enforce using the theme switching hooks and HOCs. Also move theme color files to @styles/theme/themes, so that we don't have to adapt ESLint rules once there are new themes coming.

Fixed Issues

$ #21671
$ #29911
PROPOSAL:

Tests

Verify that no errors appear in the JS console

Build the app on all platforms
Go through all the main flows
Test functionality if there are any console errors (most important)
Test for unexpected behaviour when it comes to themes/styling

(We mostly changed code imports in this PR, so functionality shouldn't be affected)

Offline tests

QA Steps

Verify that no errors appear in the JS console

Same as in Tests.

Additionally:

Check that there are no console errors on all platforms
Check that fonts look as expected (no font changes)

PR Author Checklist

I linked the correct issue in the ### Fixed Issues section above
I wrote clear testing steps that cover the changes made in this PR
- I added steps for local testing in the Tests section
- I added steps for the expected offline behavior in the Offline steps section
- I added steps for Staging and/or Production testing in the QA steps section
- I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
- I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
I included screenshots or videos for tests on all platforms
I ran the tests on all platforms & verified they passed on:
- Android: Native
- Android: mWeb Chrome
- iOS: Native
- iOS: mWeb Safari
- MacOS: Chrome / Safari
- MacOS: Desktop
I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
I followed proper code patterns (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
- I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
  - If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
- I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
- I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
- I verified the JSDocs style guidelines (in STYLE.md) were followed
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I followed the guidelines as stated in the Review Guidelines
I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
I verified that if a function's arguments changed that all usages have also been updated correctly
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label so the design team can review the changes.
If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

melvin-bot · 2023-12-06T15:48:26Z

Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers!

melvin-bot · 2023-12-06T15:54:50Z

@marcaaron Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

grgia

#21671 #29911 here's the two issue links. Should we hold this on the styleutils PR for the few lint errors?

grgia

You'll want to also update paths in the tests folder for JEST

.eslintrc.js

marcaaron

LGTM apart from the style issues

chrispader · 2023-12-07T13:40:02Z

Merged changes from #32498 in order to properly update the ESLint rules. Let's merge the other PR first

grgia

LGTM, I think we can create another issue to handle the font case separately from StyleUtils but the lint rule logic preventing util imports makes sense to me!

src/components/HTMLEngineProvider/BaseHTMLEngineProvider.js

situchan · 2023-12-23T23:17:23Z

Does this require C+ review based on #32569 (comment)?

src/components/ThemeStylesProvider.tsx

src/libs/Navigation/AppNavigator/createModalCardStyleInterpolator.ts

grgia · 2024-01-03T17:32:04Z

tests/ui/UnreadIndicatorsTest.js

@@ -488,7 +488,7 @@ describe('Unread Indicators', () => {
                const hintText = Localize.translateLocal('accessibilityHints.chatUserDisplayNames');
                const displayNameTexts = screen.queryAllByLabelText(hintText);
                expect(displayNameTexts).toHaveLength(1);
-                expect(lodashGet(displayNameTexts[0], ['props', 'style', 'fontWeight'])).toBe(fontWeightBold);
+                expect(lodashGet(displayNameTexts[0], ['props', 'style', 'fontWeight'])).toBe(FontUtils.fontWeight.bold);


Could you add some QA steps that cover the font changes?

I did. Is that not enough?

Same as in Tests.

Additionally:

Check that there are no console errors on all platforms

Check that fonts look as expected (no font changes)

grgia · 2024-01-03T18:16:44Z

@situchan if you're able to finish the checklist today, I can add you as C+. Otherwise, I'll finish it internally.

situchan · 2024-01-03T18:18:35Z

I can finish in an hour

situchan · 2024-01-03T19:54:12Z

Code looks good. Reviewed the whole diff.
Testing

situchan · 2024-01-03T20:45:22Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified tests pass on all platforms & I tested again on:
- Android: Native
- Android: mWeb Chrome
- iOS: Native
- iOS: mWeb Safari
- MacOS: Chrome / Safari
- MacOS: Desktop
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
- I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
- I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
- I verified the JSDocs style guidelines (in STYLE.md) were followed
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label so the design team can review the changes.
If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

android.mov

Android: mWeb Chrome

mchrome.mov

iOS: Native

ios.mov

iOS: mWeb Safari

msafari.mov

MacOS: Chrome / Safari

web.mov

MacOS: Desktop

desktop.mov

situchan

NAB: any reason for capitalizing the first character in FontUtils, while all others are lowercased?

situchan · 2024-01-03T20:53:19Z

Ah reviewer checklist is failing here. Missing 3 new checklist items

chrispader · 2024-01-04T15:08:47Z

NAB: any reason for capitalizing the first character in FontUtils, while all others are lowercased?

We removed usages of any other "style utils", so there is only the useStyleUtils hook (which gives us StyleUtils (also capitalized first letter) and FontUtils.

So yes, this is by design :)

grgia · 2024-01-05T02:57:39Z

@situchan I think your checklist might be out of date

grgia · 2024-01-05T03:00:16Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified tests pass on all platforms & I tested again on:
- Android: Native
- Android: mWeb Chrome
- iOS: Native
- iOS: mWeb Safari
- MacOS: Chrome / Safari
- MacOS: Desktop
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
- I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
- I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
- I verified the JSDocs style guidelines (in STYLE.md) were followed
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label so the design team can review the changes.
If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

grgia · 2024-01-05T03:02:31Z

Not sure what's up with the review checklist, but NAB gonna merge

situchan · 2024-01-05T03:03:41Z

@grgia #32569 (comment) was the issue, so I commented here 🙂

This PR has now 3 reviewer checklists 😄

OSBotify · 2024-01-05T03:06:32Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

grgia · 2024-01-05T03:16:05Z

@situchan it did not pass with any of those

OSBotify · 2024-01-09T05:35:51Z

🚀 Deployed to staging by https://github.com/grgia in version: 1.4.23-0 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

OSBotify · 2024-01-10T06:03:06Z

🚀 Deployed to production by https://github.com/thienlnam in version: 1.4.23-4 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	failure ❌
🕸 web 🕸	success ✅

chrispader marked this pull request as ready for review December 6, 2023 15:54

chrispader requested a review from a team as a code owner December 6, 2023 15:54

melvin-bot bot requested review from marcaaron and removed request for a team December 6, 2023 15:54

grgia reviewed Dec 6, 2023

View reviewed changes

.eslintrc.js Outdated Show resolved Hide resolved

marcaaron reviewed Dec 7, 2023

View reviewed changes

chrispader changed the title ~~Theme switching ESLint rules~~ [HOLD on #32498] Theme switching ESLint rules Dec 7, 2023

chrispader added 2 commits December 7, 2023 17:04

update eslint

0095fc7

add eslint ignores

8aa81be

chrispader force-pushed the @chrispader/theme-switching-eslint-rules branch from 5833ce7 to 8aa81be Compare December 7, 2023 16:05

grgia changed the title ~~[HOLD on #32498] Theme switching ESLint rules~~ Theme switching ESLint rules Dec 8, 2023

This comment was marked as outdated.

Sign in to view

chrispader changed the title ~~Theme switching ESLint rules~~ [HOLD on #32679] Theme switching ESLint rules Dec 8, 2023

grgia changed the title ~~[HOLD on #32679] Theme switching ESLint rules~~ [HOLD 32679]Theme switching ESLint rules Dec 8, 2023

chrispader changed the title ~~[HOLD 32679]Theme switching ESLint rules~~ Theme switching ESLint rules Dec 13, 2023

Christoph Pader added 7 commits December 14, 2023 00:52

Merge branch 'main' into @chrispader/theme-switching-eslint-rules

8879e2c

update eslint rules

26fa87e

fix: storybook

7dc7d8e

fix: style util structure

b756433

fix: more imports

157548e

fix: illustrations type

8db99c5

remove staticStyleUtils export

41d4b83

grgia requested review from marcaaron and grgia December 14, 2023 00:56

grgia previously approved these changes Dec 14, 2023

View reviewed changes

grgia reviewed Dec 14, 2023

View reviewed changes

src/components/HTMLEngineProvider/BaseHTMLEngineProvider.js Outdated Show resolved Hide resolved

Merge branch 'main' into @chrispader/theme-switching-eslint-rules

46a49d1

grgia reviewed Jan 3, 2024

View reviewed changes

src/components/ThemeStylesProvider.tsx Show resolved Hide resolved

grgia reviewed Jan 3, 2024

View reviewed changes

src/libs/Navigation/AppNavigator/createModalCardStyleInterpolator.ts Show resolved Hide resolved

grgia reviewed Jan 3, 2024

View reviewed changes

fix merge conflicts

220c545

situchan approved these changes Jan 3, 2024

View reviewed changes

melvin-bot bot requested a review from grgia January 3, 2024 20:49

Christoph Pader added 2 commits January 4, 2024 16:04

Merge branch 'main' into @chrispader/theme-switching-eslint-rules

32f176f

fix: lint

3b0e1a4

Merge branch 'main' into @chrispader/theme-switching-eslint-rules

99ca991

grgia approved these changes Jan 5, 2024

View reviewed changes

grgia merged commit 2d455bf into Expensify:main Jan 5, 2024
14 of 15 checks passed

github-actions bot mentioned this pull request Jan 9, 2024

Deploy Checklist: New Expensify 2024-01-09 #34121

Closed

87 tasks

grgia mentioned this pull request Jan 9, 2024

[HOLD for payment 2024-01-17] [Hold for payment] Add ES-Lint Rules for Color Styles / using Theme Providers #21671

Closed

melvin-bot bot mentioned this pull request Jan 10, 2024

[HOLD for payment 2024-01-17] Rename "default.ts" to "dark.ts" after theme switching migration is done #29911

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Theme switching ESLint rules #32569

Theme switching ESLint rules #32569

chrispader commented Dec 6, 2023 •

edited

Loading

melvin-bot bot commented Dec 6, 2023

melvin-bot bot commented Dec 6, 2023

grgia left a comment •

edited

Loading

grgia left a comment

marcaaron left a comment

chrispader commented Dec 7, 2023

This comment was marked as outdated.

grgia left a comment

situchan commented Dec 23, 2023

grgia Jan 3, 2024

chrispader Jan 3, 2024

grgia commented Jan 3, 2024

situchan commented Jan 3, 2024

situchan commented Jan 3, 2024

situchan commented Jan 3, 2024

situchan left a comment

situchan commented Jan 3, 2024

chrispader commented Jan 4, 2024

grgia commented Jan 5, 2024

grgia commented Jan 5, 2024

grgia commented Jan 5, 2024

situchan commented Jan 5, 2024 •

edited

Loading

OSBotify commented Jan 5, 2024

grgia commented Jan 5, 2024

OSBotify commented Jan 9, 2024

OSBotify commented Jan 10, 2024

Theme switching ESLint rules #32569

Theme switching ESLint rules #32569

Conversation

chrispader commented Dec 6, 2023 • edited Loading

Details

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

melvin-bot bot commented Dec 6, 2023

melvin-bot bot commented Dec 6, 2023

grgia left a comment • edited Loading

Choose a reason for hiding this comment

grgia left a comment

Choose a reason for hiding this comment

marcaaron left a comment

Choose a reason for hiding this comment

chrispader commented Dec 7, 2023

This comment was marked as outdated.

grgia left a comment

Choose a reason for hiding this comment

situchan commented Dec 23, 2023

grgia Jan 3, 2024

Choose a reason for hiding this comment

chrispader Jan 3, 2024

Choose a reason for hiding this comment

grgia commented Jan 3, 2024

situchan commented Jan 3, 2024

situchan commented Jan 3, 2024

situchan commented Jan 3, 2024

Reviewer Checklist

Screenshots/Videos

situchan left a comment

Choose a reason for hiding this comment

situchan commented Jan 3, 2024

chrispader commented Jan 4, 2024

grgia commented Jan 5, 2024

grgia commented Jan 5, 2024

Reviewer Checklist

Screenshots/Videos

grgia commented Jan 5, 2024

situchan commented Jan 5, 2024 • edited Loading

OSBotify commented Jan 5, 2024

grgia commented Jan 5, 2024

OSBotify commented Jan 9, 2024

OSBotify commented Jan 10, 2024

chrispader commented Dec 6, 2023 •

edited

Loading

grgia left a comment •

edited

Loading

situchan commented Jan 5, 2024 •

edited

Loading